En el Chapter 6, instalamos el paquete Udev. Antes de entrar en los detalles sobre cómo funciona esto, veámos una breve historia de los métodos anteriores de manipulación dispositivos:
Los Sistemas Linux en general utilizan tradicionalmente un método de creación de dispositivo estático, en el que un gran número de nodos de dispositivo son creados en /dev (literalmente, cientos de nodos), sin importar si realmente existen los dispositivos de hardware correspondientes. Esto se realiza normalmente a través de un script MAKEDEV , que contiene una serie de llamadas al programa mknod con los números de dispositivo mayor y menor correspondientes a cada posible dispositivo que pudiera existir en el mundo.
Utilizando el método Udev, sólo a aquellos dispositivos que son detectados por el kernel se les adjudica y crea nodos de dispositivo. Debido a que estos nodos de dispositivo se crean cada vez que se arranque el sistema, se pueden almacenar en un sistema de archivos devtmpfs (un sistema de archivos virtual que reside enteramente en la memoria del sistema). Los nodos de dispositivo no necesitan mucho espacio, por lo que la memoria que se utiliza es insignificante.
En febrero de 2000, un nuevo sistema de ficheros llamado devfs fue incluido en los núcleos 2.3.46 y estuvo disponible en la serie 2.4 de los núcleos estables. A pesar de que estaba presente en el propio código fuente del núcleo, este método de creación dinámica de dispositivos nunca recibió un apoyo abrumador de los desarrolladores del núcleo.
El principal problema con el enfoque adoptado por devfs era el modo en que manejaba la detección, creación y denominación. El último punto, el de dispositivo de nodo de nombres, fue quizás el más crítico. En general se acepta que si los nombres de dispositivo pueden ser configurables, entonces la política de nombres de dispositivos debe estar al cargo administrador del sistema, y no ser impuestos por un desarrollador en particular. El sistema de ficheros devfs sufre también de unas raras condicioneque son inherentes a su diseño y que no pueden corregirse sin una revisión sustancial del núcleo. Fue marcado como obsoleto desde hace mucho Espacio requerido en disco - debido a una falta de mantenimiento - y fue retirado finalmente del kernel en junio de 2006.
Con el desarrollo de la inestable 2.5 del kernel, posteriormente liberado como la serie 2.6 de los núcleos estables, un nuevo sistema de ficheros virtual llamado sysfs apareció. El trabajo de sysfs es exportar una vista de la configuración del hardware del sistema para los procesos de usuario. Con esta representación del espacio de usuario visible, la posibilidad de encontrar un sustituto para el espacio de usuario de devfs se convirtió en mucho más realista.
El sistema de archivos sysfs fue mencionado brevemente más arriba. Uno podría preguntarse cómo conoce sysfs los dispositivos presentes en el sistema y qué números de dispositivo se deben utilizar para ellos. Los drivers que se han compilado en el núcleo registran sus objetos en un sysfs (devtmpfs internamente), ya que son detectados por el kernel. Para los controladores compilados como módulos, esto sucederá cuando se cargue el módulo. Una vez montado el sistema de ficheros sysfs (en / sys), los datos que se registran con los controladores sysfs están disponibles para los procesos de usuario y para udevd para procesamiento (incluyendo modificaciones a los nodos de dispositivos).
Los ficheros de dispositivos son creados por el núcleo por el sistema de archivos devtmpfs. Cualquier driver que desee registrar un nodo de dispositivo pasará por devtmpfs (a través del núcleo del driver) para hacerlo. Cuando se monta una instancia devtmpfs en /dev, el nodo del dispositivo será el que se crea con un nombre fijo, permisos y propietario.
Poco Espacio requerido en disco después, el kernel envía un uevent a udevd. Sobre la base de las normas especificadas dentro de los archivos /etc/udev/rules.d,/lib/udev/rules.d y /run/udev/rules.d, udevd creará enlaces simbólicos adicionales para el nodo del dispositivo, o podrá cambiar los permisos, propietario, o grupo, o modificar la entrada de la base de datos udevd interna (nombre) para ese objeto.
Las reglas en estos tres directorios están numeradas de forma similar al de los scripts de arranque y los tres directorios se combinan entre sí. Si udevd no puede encontrar una regla para el dispositivo que está creando, va a dejar los permisos y la propiedad a los quer usa por defecto devtmpfs inicialmente.
El primer script de arranque LFS /etc/init.d/mountvirtfs copiará todos los dispositivos ubicados en /lib/udev/devices a /dev. Esto es necesario debido a que algunos dispositivos, directorios y enlaces simbólicos son necesarios antes de que los procesos dinámicos de manejo de dispositivo estén disponibles durante las primeras fases del arranque del sistema, o son requeridos por el mismo udevd . La creación de ficheros de dispositivos estáticos en /lib/udev/devices también proporciona una solución fácil para los dispositivos que no son compatibles con el dispositivo de infraestructura de manejo dinámico.
El archivo /etc/rc.d/init.d/udev initscript inicia udevd, desencadena cualquier dispositivo "coldplug" que ya hn sido creado por el kernel y espera a cualquier regla para completar. El script también desarma el controlador uevent de /sbin/hotplug. Esto se hace debido a que el kernel ya no tiene que llamar a un binario externo. En su lugar, udevd escucha en un conector de red los uevents que el núcleo plantea.
El script de inicio /etc/rc.d/init.d/udev_retry
se ocupa de los acontecimientos de re-activación de subsistemas cuyas normas pueden depender de sistemas de archivos que no se montan hasta que se ejecuta el script mountfs (en particular, /usr y /var puede causar esto). Este script se ejecuta después de la secuencia de comandos mountfs, por lo que esas reglas (si son re-activadas) se harían efectivas la segunda vez. Se configura desde el archivo /etc/sysconfig/udev_retry. Cualquier palabra en este archivo que no sean los comentarios se consideran nombres de subsistema para activar en Espacio requerido en disco de reintento. Para encontrar el subsistema de un dispositivo, utilice udevadm info --attribute-walk "device" donde "device" es una ruta absoluta a /dev or /sys such as /dev/sr0 or /sys/class/rtc.
Los controladores de dispositivos compilados como módulos pueden haber alias incorporado en ellas. Los alias son visibles en la salida del programa modinfo y normalmente están relacionados con los identificadores específicos de bus de dispositivos soportados por el módulo. Por ejemplo, el controlador snd-FM801 es compatible con los dispositivos PCI con 0x1319 ID de proveedor y 0x0801 ID de dispositivo, y tiene un alias de "pci: v00001319d00000801sv * sd * bc04sc01i *". Para la mayoría de los dispositivos, el controlador del bus exporta el alias del controlador que se ocuparía el dispositivo a través de sysfs.
Por ejemplo, el archivo /sys/bus/pci/devices/0000: 00:0 d.0/modalias podría contener la cadena "pci: v00001319d00000801sv00001319sd00001319bc04sc01i00". Las reglas predeterminadas proporcionadas con Udev harán que udevd llame a /sbin modprobe con el contenido de la variable de entorno uevent MODALIAS (que debe ser el mismo que el contenido del archivo modalias en sysfs), cargando todos los módulos cuyos alias contengan esta cadena después de la expansión de tarjeta.
En este ejemplo, esto significa que, además de-SND FM801, el obsoleto (y no deseado) driver fuerte se cargará si está disponible. Vea a continuación las formas en que la carga de los drivers no deseados se puede prevenir.
El kernel en sí también es capaz de cargar los módulos para protocolos de red, sistemas de archivos y soporte NLS bajo demanda.
Cuando se conecta un dispositivo, como un bus serie universal (USB) Reproductor de MP3, el núcleo reconoce que el dispositivo está conectado y genera un uevent. Este uevent es manejado por udevd como se describió anteriormente. above.
Hay algunos problemas posibles cuando se trata de la creación automática de nodos de dispositivos.
Udev cargará un módulo si tiene un alias específico del bus y el driver de ese bus exporta correctamente los alias necesarios a sysfs. En otros casos, se debe organizar módulo de carga por otros medios. Con Linux-3.13.3, Udev sabe que ha de cargar los controladores apropiados para dispositivos de entrada, IDE, PCI, USB, SCSI, SERIO, y FireWire.
Para determinar si el controlador de dispositivo que necesitas tiene el soporte necesario para Udev, ejecuta modinfo con el nombre del módulo como argumento. Ahora intenta localizar el directorio del dispositivo en
/sys/bus y comprueba si hay un archivomodalias justo allí.
Si el archivo modalias existe en sysfs, el driver soporta el dispositivo y puede hablar con él directamente, pero si no tiene el alias, entonces existe un bug o error en el controlador. Carga el controlador sin la ayuda de Udev y espera que el problema se resuelva más adelante.
Si no hay ningún archivo modalias en el directorio correspondiente bajo/sys/bus,
esto significa que los desarrolladores del núcleo no han añadido soporte modalias a este tipo de buses. Con Linux-3.13.3, este es el caso de los buses ISA. Espera a que este problema sea solucionado en versiones posteriores del kernel.
Udev no está diseñado para cargar controladores “wrapper” tales como snd-pcm-oss y no-hardware drivers tales como loop.
Si el módulo "contenedor" sólo mejora la funcionalidad proporcionada por otro módulo (por ejemplo, snd-pcm-oss mejora la funcionalidad de snd-pcm haciendo que las tarjetas de sonido disponible para las aplicaciones de software libre), configure modprobe para cargar el envoltorio después de que Udev cargue el módulo envuelto. Para ello, agregue una línea“softdep” en cualquier archivo /etc/modprobe.d/
Por ejemplo:
<filename>.conf
softdep snd-pcm post: snd-pcm-oss
Tenga en cuenta que el comando “softdep” también permite
pre: dependencias, o una mezcla de ambas pre: y post:. Vea la página de manual obtener más información sobre la sintaxis y las capacidades "softdep".
Si el módulo en cuestión no es un contenedor y es útil por sí mismo, configura los módulos de los scripts de arranque para cargar este módulo en el arranque del sistema. Para ello, agrega el nombre del módulo en el fichero
/etc/sysconfig/modules en una línea separada. Esto funciona para módulos envoltorio también, pero no es óptima en ese caso.
O no construyen el módulo, o lo ponen en la lista negra en /etc/modprobe.d/blacklist.conf como se hizo con el módulo forte en el siguiente ejemploforte module in
the example below:
blacklist forte
Módulos de lista negra se pueden cargar manualmente con el comandomodprobe
Esto suele suceder cuando una regla concuerda inesperadamente un dispositivo. Por ejemplo, una regla mal escrita puede coincidir tanto un disco SCSI (que si se deseamos) y el dispositivo genérico SCSI correspondiente (incorrecto). Encuentra la regla no deseada y hazla más específica, con la ayuda del comando info udevadm.
Esto puede ser una manifestación más del problema anterior. Si no fuese así, y su regla usa atributos sysfs
puede ser un problema de sincronización del núcleo, que se resolverá en las versiones posteriores del núcleo. Por ahora, se puede evitar mediante la creación de una regla que espera al atributo en usosysfs
y anexándolo al archivo /etc/udev/rules.d/10-wait_for_sysfs.rules (crear este archivo si no existe). Por favor notifique a la lista Desarrollo LFS si lo hace y le ayuda.
Se asume que el controlador ha sido compilado estáticamente en el kernel o ya cargado como un módulo, y que ya se ha comprobado que Udev no crea un dispositivo equivocado.
Udev no tiene la información necesaria para crear un nodo de dispositivo si un controlador del núcleo no exporta sus datos a sysfs. Esto es más común con los drivers de terceros ajenos al árbol del núcleo. Cree un nodo de dispositivo estático en /lib/udev/devices con los números mayor/menor apropiados (véa el archivo devices.txt dentro de la documentación del núcleo o de la documentación proporcionada por el fabricante del controlador de terceros). El nodo de dispositivo estático será copiado en /dev por el script de arranqueudev
Esto es debido al hecho de que Udev, por diseño, se encarga de uevents y carga los módulos en paralelo, y por lo tanto en un orden impredecible. Esto nunca será, por lo tanto, algo “fijo”.Usted no debe confiar en los nombres de los dispositivos del kernel siendo estable. En su lugar, creae sus propias reglas para crear enlaces simbólicos con nombres estables basados en algunos atributos estables del dispositivo, como un número de serie o la salida de varias utilidades *_id instaladas por Udev. Consulte Section 7.5, “Creating Custom Symlinks to Devices” y Section 7.2, “General Network Configuration”para más ejemplos.
Documentación de ayuda adicional está disponible en los siguientes sitios:
Un espacio de usuario de implemanetación de devfs
http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf
Los Sistemas de Ficheros sysfs
http://www.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf